A system on chip (SoC), such as microcontroller unit (MCU), includes software and hardware that are custom designed. The intricacies of the interdependencies between the software and hardware components require extensive validation prior to production of the SoC. Given the competitiveness of the electronics industry, time to market is critical. Consequently, manufacturers of such systems strive to reduce the duration of software development process and hardware verification process.
The software development process and hardware verification process are typically performed independently, but in parallel, ensuring that the SoC meets predetermined design requirements. The functionality of software may be validated using an instruction set simulator. The hardware verification process may be done using a hardware simulator or emulator. Software and hardware are generally not tested together until a prototype of the hardware is available, which is typically at the latter part of the hardware development process. It is common for the software development process and hardware verification process to have overlapping test cases. However, in such cases, there is parallel effort to write multiple sets of software codes independently, using multiple programming languages, albeit one set of software code could be translated and re-used for another to generate the same test case.
In order to share software codes between the software development process and hardware verification process, software/hardware co-verification processes are sometimes used. However, existing software/hardware co-verification processes can only achieve functional behavior validity testing between hardware components and their software counterparts, and tend to ignore non-functional system aspects such as scheduling, timing, etc. For example, existing co-verification processes do not test for corner-case constraints enforced on transactions via an interconnect, which bridges a central processing unit (CPU) of the SoC and its hardware peripherals. An example of such a corner-case constraint is a command queue stall, which undesirably imparts command queues out of order, potentially leading to communication failures. Therefore, the development process related to interconnects requires an additional level of verification at a low-level hardware layer to cover test case scenarios that are not reachable from a high-level application layer of existing software/hardware co-verification processes.